1. Technical Field
This disclosure relates generally to security systems for computer networks.
2. Background of the Related Art
When defining an access control policy for an organization a common approach is to implement Role Based Access Control (RBAC). Using RBAC, entitlements to perform particular functions are assigned to roles instead of directly to users. The way a user gets the entitlements is by being assigned to roles or requesting membership of the role. Thus, to define an RBAC-based policy for an organization, an understanding of the user roles and the entitlements for those roles is required. Once this information is understood for an organization, the appropriate RBAC policy can be defined and deployed to an Identity Management system, such as IBM® Tivoli® Identity Manager™. Use of such tools greatly simplifies access management as compared with directly defining a user-to-entitlement relationship.
A problem, however, is how to create an initial RBAC policy for an organization. A particular issue is how to discover the roles and the entitlements for those roles, especially in a large organization. There are a number of common approaches that together are used to address these issues and to facilitate the defining of the RBAC policy. A typical approach involves several manual steps including interviewing each employee (about their job function and application entitlements), interviewing management (asking their view on employee roles and entitlements), performing system review (e.g., examining application user directories for user entitlements such as group membership), reviewing documentation (e.g., examining documents that define the management structure of an organization and job definitions), and evaluating best practices (i.e., trying to use roles and entitlements defined in other organizations and then tailoring these to the current enterprise). These approaches, however, are very expensive and time-consuming, and they rarely result in a meaningful RBAC policy. Indeed, it is not uncommon for an enterprise to embark on a role-defining exercise and then much later decide that no useful policy has resulted (in which case the entire exercise may then be abandoned). This is because manual processes just are not efficient at discovering the true roles and entitlements of an organization.
Another problem is that, with respect to an identity solution, the definition of what is or is not a role is often confusing (especially to individuals being questioned about employee “roles”), because most organizations use the term to identify job description rather than the person's need for access to systems. Indeed, some individuals being interviewed about roles may not even understand or appreciate the distinction (between an IT-based RBAC role and an employment role), which further skews any results toward a negative or un-useful outcome.
It is also known in the art to provide automated organizational role modeling for role based access controls. This approach inspects permission settings within IT systems, and these settings are then analyzed to determine whether there are any patterns within these permissions. Automated role modeling using the above-described approach, however, tends to produce roles that track existing policy set by the organization as opposed to roles that more closely indicate the actual behavior of users within the organization. Another approach, which typically is implemented in identity management systems, provides for role mining capabilities and the ability to model new roles based on policy information. That approach, however, typically relies upon static information.
There remains a need in the art to provide enhanced role and entitlements mining that addresses these and other problems.